【コストに注意】CloudWatch Logs Insightsのスキャン容量はCloudWatch Logsに取り込まれる圧縮前のデータ量です
こんにちは!AWS事業本部のおつまみです。
みなさん、 CloudWatch Logs Insights普段活用していますか?私は活用しています。
CloudWatch Logs Insightsは、CloudWatch Logs 内にあるログデータを効率的に分析し、有用な洞察を得るための強力なツールです。
大変便利な機能ですが、コスト面で注意すべきポイントがあります。
そこで今回は実際に起きてしまった具体的な事象を交えて、CloudWatch Logs Insightsを使用する際に知っておくべき重要な点についてご紹介をします。
いきなり結論
- CloudWatch Logs Insightsは スキャンされる容量 あたりのコストがかかる。
- スキャンされるデータ容量はCloudWatch Logsに保管される 圧縮前 のデータ容量である。
- CloudWatch Logs に保存されるデータは元のデータの 15% 程度 まで自動圧縮されるようだが、データ形式によっては さらに圧縮される 可能性がある。
- CloudWatch Logs Insightsでクエリを投げる場合には、スキャンする際のデータ量が削減されるようクエリを最適化しよう。
今回起きてしまった事象について
事象
今回とある環境でCloudWatch Logsのコストが急激に増加していました。(調査時点で約4.7TBのログを取り込んでおり、$3,000強のコストが発生していました。)
原因調査①
まずどのログが原因かを調査するため、Cloudwatch Logsへのログ取り込み量メトリクスincomingBiytes
を確認しました。すると、Auroraのpostgresqlログの容量が肥大化していることが判明しました。
そして、postgresqlログをCloudWatch Logsで確認したところ主に監査ログやスロークエリログなどが出力されていることが確認できました。(AUDIT
で始まるログが監査ログ、duration
で始まるログがスロークエリログです。)
原因調査②
ログ容量削減するために、postgresqlログに対して監査ログやスロークエリログがどのくらいの割合を占めているか確認することにしました。
そこでCloudWatch Logs Insights でスロークエリログのみの容量を把握しようと、8/1~8/13の期間で以下のクエリを実行しました。
fields @timestamp, @message
| filter @message like /duration:/
| stats sum(strlen(@message)) as total_size
すると、CloudWatch Logs のデータ保管容量は約200GBだったのに対し、4.2TBのデータがスキャンされてしまいました。
- CloudWatch Logs のデータ保管容量(約200GB)
- CloudWatch Logs Insights でスキャンしたデータ容量(4.2TB)
その結果、たった1回のクエリで約$30のコストが発生してしまいました。。。
判明したこと
今回起きてしまった事象によって、以下の2点が判明しました。
- CloudWatch Logs Insightsでスキャンされるデータ容量はCloudWatch Logsに保管される 圧縮前 のデータ容量である。
- CloudWatch Logs に保存されるデータは元のデータの 15% 程度 まで自動圧縮されるようだが、データ形式によっては さらに圧縮される 可能性がある。
内容を掘り下げたいと思います。
CloudWatch Logs Insightsのコストについて
CloudWatch Logs Insightsのコストはスキャンされたデータ容量に対して、コストが発生します。
分析 (Logs Insights のクエリ) スキャンしたデータ 1 GB あたり USD 0.0076(東京リージョン)
引用:料金 - Amazon CloudWatch | AWS
ここで注目すべき重要なポイントがあります。
今回の事象で判明したようにCloudWatch Logs Insightsでスキャンされるデータ量は、CloudWatch Logsに取り込まれる 圧縮前 の容量であるということです。つまり、実際にCloudWatch Logsに保存されているデータ量よりも多くのデータがスキャンの対象となり、それに応じてコストが発生します。
CloudWatch Logsのデータ圧縮は必ずしも15%にはならないこと
CloudWatch Logs に取り込まれたログは AWS によって自動で元のデータの 15% 程度まで圧縮されるといわれています。
AWS Pricing Calculatorで、4.2TBのデータ量を取り込んだ時のコストを計算してみると、0.15 ストレージ圧縮係数
が存在しています。
このことから、ログボリュームはアーカイブ後、取り込まれたログボリュームの15%になると推測されます。
しかし、今回CloudWatch Logs の保管されていたデータ容量は約200GBでした。15%の圧縮率を想定すると、4.2TB × 0.15 = 0.63TB (630GB)になるはずです。
いったいなぜでしょうか??
この差異の理由は、CloudWatch Logs の 圧縮形式と元データの特性 によるものと考えられます。
CloudWatch Logs の圧縮形式はgzip レベル 6 圧縮であることが公式ドキュメントに記載されています。
CloudWatch Logs から Amazon Data Firehose に送信されるデータは、すでに gzip レベル 6 圧縮で圧縮されているため、Firehose 配信ストリーム内で圧縮を使用する必要はありません。
gzipレベル6の圧縮率は通常15%程度ですが、テキストデータで同じような内容が繰り返し出力される場合、圧縮率はさらに高まる傾向があります。
gzip圧縮の圧縮率は、元のデータの性質によって大きく異なります。一般的に、テキストデータや繰り返しパターンが多いデータは、高い圧縮率が得られる傾向にあります。
引用:圧縮コマンドのgzipとは?意味をわかりやすく簡単に解説 – xexeq.jp
今回のpostgresqlログは、監査ログやスロークエリログが中心で、 同じ文字列が頻繁に出現していたため 、元のログデータ容量よりもかなり圧縮されたと考えられます。
結論として、CloudWatch Logs に保存されるデータは元のデータの15%程度まで自動圧縮されるが、データの特性によってはさらに高い圧縮率が達成される可能性があることが判明しました。
CloudWatch Logs Insightsのコスト最適化のためのヒント
今回CloudWatch Logs Insightsのコストが想定より発生してしまいましたが、どのようにすればよかったのでしょう?
以下の方法でコスト最適化を図ることができます。
クエリ内容を見直す
まず、クエリの内容を見直すことが重要です。
クエリ対象範囲の指定、実行頻度の見直しなどが効果的です。
詳細はこちらのブログをご参考ください。
なおクエリの内容によるスキャン量は削減できないので、ご注意ください。
詳細はこちらのブログをご参考ください。
CloudWatch Logsの容量を抑える
次に、スキャン対象となるCloudWatch Logsの容量を抑えることも重要です。
ログの保持期間を適切に設定し、不要なログを自動的に削除することで、CloudWatch Logs自体のコストを削減できます。さらに、ログフィルタを使用して重要なログのみを保存したりすることも有効です。
詳細はこちらのブログをご参考ください。
最後に
今回は、CloudWatch Logs Insightsのコストについてご紹介しました!
CloudWatch Logs Insightsヘビーユーザーの皆さんも想定外のコストが発生していないか確認してみてください!
最後までお読みいただきありがとうございました!
以上、おつまみ(@AWS11077)でした!
参考
- 料金 - Amazon CloudWatch | AWS
- [小ネタ] CloudWatch Logsに保存されているログの総容量をAWS CLIからサクッと確認する | DevelopersIO
- Amazon S3とCloudWatch Logsのログ保存料金とサイズを見てみた | DevelopersIO
- CloudWatch Logs と S3 にかかる料金比較 | DevelopersIO
- ロググループレベルのサブスクリプションフィルター
- 圧縮コマンドのgzipとは?意味をわかりやすく簡単に解説 – xexeq.jp
- CloudWatch Logs Insightsでログを調査する前に読む記事 | DevelopersIO
- CloudWatch Logs のコストを最適化する方法を教えてください | DevelopersIO
- CloudWatch Logs Insights のクエリがスキャン量に影響するか確認してみた | DevelopersIO